1. Field of the Invention
The invention relates to an advanced IPMI system with multi-message processing and configurable performance and method for the same, and more particularly, to an IPMI system and method for the same for server management.
2. Description of the Prior Art
As known in the art, when remote servers, such as telecommunications equipment, computer stations, and especially ISP servers are out of order, a system manager must go to the server's location to fix the breakdown. This requires a lot of manpower and time. To solve this issue, management technology for remote servers, such as an intelligent platform management interface (IPMI), has gradually been developed.
The IPMI mainly comprises a hardware structure, i.e., a micro-controller having a baseboard management controller (BMC) and firmware embedded in the BMC. The IPMI is actually a server management subsystem operating independently from server hardware such as the central process unit (CPU), basic input/output system (BIOS), and software such as the operating system (OS) and system management software (SMS). The IPMI controls the system management software and the interface of the platform management hardware, especially when failure of the CPU, the BIOS, and/or the OS of the server occurs.
Most of the BMC micro-controllers of the IPMI integrate with an A/D converter for monitoring voltage, a fan speed counter, and an IO and a bus for a sensor. As a watchdog timer of the IPMI detects a fault of the CPU, BIOS, OS, or application program of the servers, the IPMI provides a platform event filter (PEF) to correct a fault or follow instructions from the operating terminal on fault correction. Moreover, the IPMI automatically provides system status detection of software/hardware of the servers, an event diary log, system rebooting control, automatic alarm for the event, and auto-system control (such as system power off). For example, the BMC micro-controller of the IPMI utilizes an I2C digital sensor to obtain by polling the measurement of the host system to monitor the system voltage, temperature, and fan speed variations of the remote host system. The IPMI then decides whether the monitored data exceed the default range and sends an I2C sensing data (an IPMI message) through an intelligent platform management bus (IPMB) or communicates with the host system through a system management bus (SMBus) interface. Any system exception will be immediately recorded in a system event log (SEL) and the IPMI will call for the PEF to find a response action that matches the exception, for instance, cutting off the power supply, re-plugging in the power, rebooting, sending/broadcasting a warning, and so forth.
The IPMI can further allow a remote operating terminal for transmitting through a local area network (LAN) an IPMI message packet conforming to remote mail checking protocol (RMCP) and user datagram protocol/internet protocol (UDP/IP) or remotely monitoring/controlling servers with serial messages of serial modem (such as a universal asynchronous receiver/transmitter, UART) interface protocol for accessing the monitored data for immediate fault correction to a critical event. When the temperature of said server over-ranges significantly, the IPMI keeps track of the event log for future reference and automatically exterminates the problem by speeding up the system fan for more heat dissipation and sending a broadcast caution on local area network (LAN), that is, sending to the remote operating terminal a simple network management protocol (SNMP) trap of platform event traps (PET) or a caution of a serial modem. The operating terminal, host system, or BMC controller of the IPMI receives/sends an IPMI channel message for the firmware of the IPMI to process and respond through some different fixed channels, such as intelligent platform management bus (IPMB), keyboard control style application interface (KCS), intelligent chassis management bus (ICMB), universal asynchronous receiver/transmitter (UART), or local area network (LAN).
What needs to be noticed is that the IPMI system cannot directly access hardware data of a sensor unit such as an I2C sensor but accesses said data by generating a sensor command such as ‘Get Sensor Reading’ through a sensor management unit such as a management controller.
However, firmware design of the generic IPMI is still not perfect and some drawbacks exist:
(1) As an IPMI massage passes through a module or a unit of the firmware, the module or unit itself needs to allocate a dedicated local memory to copy the passing IPMI message for later passing, queuing, using, and implementing the IPMI message. This requires higher memory cost and lowers the IPMI performance since reading/copying the IPMI message occurs in all steps, increasing the overall system execution time.
(2) The execution unit of the prior art IPMI firmware deals with one IPMI message at a time and the rest of the IPMI messages wait in queue for the next response, dropping even more IPMI performance.
(3) Because of the interdependence of the prior art IPMI firmware units, replacement of any individual unit is unlikely, especially when the operator needs some changes of the firmware functions. Nothing can be changed unless rearranging the overall IPMI structure; therefore, no expandability and programmability is allowed to the user.
(4) The prior art IPMI firmware requires a sensor management unit such as a management controller to access a sensing event in an electrically erasable programmable read only memory (EEPROM) of a sensor unit. However, the access speed of the EEPROM is pretty low. The EERPOM will be busy and then jammed in the data bus if lots of IPMI messages are in queue. Especially when the EEPROM shares the data bus with other devices, lots of data collisions will make the system even more sluggish.
(5) The prior art IPMI firmware is unable to automatically coordinate with too many different types of hardware such as BMC controllers or different types of operating systems (OSs).